Vol 1 Issue 6 
$4.50 US 


Virtual Reality and the IBM Personal Computer 





| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
i 
| 





3D sound - Theory 


3D sound - Application 


Virtual Racquetball 














UAId 7661 “AIQUIIIIG| /LIGUIAON OH JUSS] 








A. this time of year, around Thanksgiving 
and Christmas, our senses are alive and hum- 
ming! November brings the smell of turkey and 
pumpkin pie, then our sense of touch sharpens _ 
up as we try to guess those presents around the 
Christmas tree. We also have the added pleasure 
of seeing the wonderful Christmas lights that 
seem to make the world sparkle! And last, but 
not least, the sound of busy Christmas shoppers 
and Christmas music to keep us in good cheer! 
What would Christmas be like without sound? 

In the previous issues, our worlds have been a 
little like Christmas without the music. There 
has been no sound sensation introduced in the 
demo programs, only visual stimuli. In this issue 
of PCVR, there are three articles that will bring 
3D sound to your virtual worlds in an attempt to 
make them seem a little more realistic. Be sure 
to check out Theory of 3D Sound, 3D Sound 
System, and Current 3D Sound Products to 
enhance your world. After all, what is your 
world without sound? 

For low-cost, alternative equipment and infor- 
mation, be sure to check out the article The 
Powerglove Serial Interface: Touching the 
Future by Jim Brain and Ben Gross. 

In changing our format we have kept most 
columns and added a few new ones. We still 
have the The Disk, on-going Graphics column 
and Working With REND386 by Joseph D. 
Gradecki. We have added What’s New, which 
reviews any new software or hardware for 
Virtual Reality. There is also a new Letters To 
The Editor section so readers may voice their 
opinion. The last page begins a new column in 
which the publisher expresses his ideas called 
My Virtual Playground. Don’t Miss It! 

Enjoy the issue and we wish everyone A Very 
Merry Christmas and A Happy New Year! 
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Diamond SpeedStar 24X 


; | 
Wh at S New \ \ e recently added the Diamond SpeedStar 24X graphics 


accelerator card to our 50 Mhz 80486 system here at PCVR. We 

are replacing an old Orchid Prodesigner Plus that was part of a 

previous system. Back in Issue 4, we reviewed the speeds of the 
first three releases of the REND386, before the demo program for Version 4.00 and 4.01 was 
released. Rend386 Version 4.01's demonstration program has a built-in speed indicator. 


Using the previous Prodesigner card, we received a constant value of 8-10 frames per second 
monoscopic and 3-4 frames per second stereoscopic using Rend386 Version 4.01. We originally 
purchased the SpeedStar to help with the Windows graphic speed, which operates very nicely. 
What we didn’t expect was the speedup for DOS applications. Now when we execute the demo 
program, we receive constant values of 30-45 frames per second monoscopic and 15-20 frames 
per second stereoscopic. If you travel outside of the demo house, we receive ratings of 90-183 
frames per second! 


This card generates 256 colors at 1024 x 768, 32K colors at 800 x 600, and 24M colors at 640 x 
480. The mail order cost is as low as $170.00 for a 1M card. If you need to upgrade your 
Windows and DOS graphics, I highly recommend this card. 


Object-Oriented Powerglove Interface 


L, late October, a new PowerGlove interface software system was introduced to the homebrew 
Virtual Reality community. This package called O2GLOVE is a C++ object-oriented interface. 
Using the familiar PowerGlove code from Dave Stampe and others, Mark Pflaging has rewritten it 
into a powerful package. OZ2GLOVE uses an interrupt driven queue to keep track of data from 
the glove and it has a timer routine that detects the proper speed at which to operate depending on 
the speed of your computer. 


There is a demonstration program that shows off all the features of the system quite nicely. The 
program begins by timing your computer and adjusting itself. Several timing values are shown for 
your examination. The system then begins reading data from the glove. Using several graphical 
representations of the glove, the program verifies the operation of the parallel PowerGlove inter- 
face. 


The software system appears to be very well designed as I saw little noise interrupting the glove. 
This is impressive considering I was using the glove in front of a roaring fireplace. The software is 
freeware and can be used to develop your. own programs as long as the appropriate credits are 
given to all of the different authors. The system can be found in the GRAPHDEY library on 
Compuserve, the /pub/rend386 directory on the Internet site sunee.uwaterloo.ca, and in the PCVR 
software library. 14 
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Letters To 


The Editor 





A s of this date, we have 


received approximately 8% of 
the survey sheets which were 
included in issue 4. The results 
of the survey are: 


1) How does PCVR rate overall? 


50% Great 
40% Good 
10% OK 


2) Are you satisfied with the 
format? 


70% Very 
20% Somewhat 
10% OK 


3) Do you like getting the soft- 
ware on a disk, instead of the 
listings? 


70% Prefer disk 
10% Prefer listings 
20% Prefer both 


EDITOR: As you know, we 
included the disk as a conve- 
nience. This eliminated using 
valuable space in the issues for 
software listings. We feel that if 
software listings are necessary, 
you can print them from the 
source code provided on the 
disk. We chose the 5.25" 360k 
floppy for compatibility purposes 
and cost. 


4) What topics would you like to 
see covered in future issues? 


Responses: 


- Hardware and software 
reviews and source 


- What other people are doing 


- Anything you can get your 
hands on 


- Realtime Interactive (systems) 
with multiple icons 


- Objects that do things 

- VR Programming Environment 
- Software 

- Authoring Tools 

- Animation 

- More on H.M.D.s 


EDITOR: We appreciate the 
great suggestions sent by the 
readers as to topics that PCVR 
should cover. Although we do 
not have enough space to cover 
all of the topics, we will have 
articles discussing: Authoring 
Tools, VR Programming Envi- 
ronment, new Head Mounted 
Display techniques, VR Operat- 
ing Systems, and software. 


There are many differnet topics 
that can be covered concerning 
Virtual Reality. In coming 
issues, we will run a series on the 
"theory" behind stereoscopic 
viewing, 


5) Would you like to have a 
Virtual Reality Bulletin Board 
started? 


80% Yes 
10% No 
10% Maybe 


Of the responses for Yes, 30% 
would like an FTP site on 
Internet. 


EDITOR: We have decided to 
establish a Virtual Reality Bulle- 
tin Board system once we finish- 
ing creating our software system 
for remote VR experiences. This 
system will allow you to dial-in 
to our system and interact Virtu- 
ally with us or other users logged 
on. We hope to be up and 
running by third quarter 1993. 


6) Any additional comments or 
suggestions. 


- ...reduce the whitespace... 


EDITOR: Our new format 
starting with Issue 6, is designed 
to reduce whitespace. We have 
changed desktop publishing 
packages to PageMaker 4.0 for 
Windows in order to help in this 
situation. This is a very profes- 
sional package which can do 
many wonderous things. 


The Letters To The Editor 
column is where we at PCVR 
get a chance to comment on 
your mail. Please feel free to 
write us and tell us how we are 
doing. If 
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| Joseph D. Gradecki : 


Sound localiza- 
tion is a function 
of our auditory 
system. This 
complex system 
allows us to pin- 
point the location 
of a sound within 
seconds. Repre- 
senting our audi- 
tory system with 
a computer is not 
SO precise. 
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\ *9 most of us think about 


a virtual world, we picture a 
scene in our mind such as that 
found in Version 4 of the 
Rend386 demo program. In this 
version of a virtual world, we are 
able to walk through a house that 
has three rooms and an outside 
area. This is a visual virtual 
world and the type most com- 
mon to current Virtual Reality 
products. If we want to add 
more realism to this virtual 
world, we need to incorporate 
additional human senses. 


Imagine a virtual world with a 
drippy kitchen faucet. In order 
to experience a more sensual 
world, we need to create the 
sound of the drip hitting the sink 
bottom using three dimensional 
sound reproduction. All normal 
activities in this virtual world 


_ would be given sound as in the 


natural world. “Is is real or is it 
memorex?” 


In this article, we investigate 
the theory of three dimen- 
sional sound localization. 


INTRODUCTION 

In order to create three 
dimensional sound, we must 
understand how the human 
localizes or finds the position of 
a sound source. We do localize 
sounds every day. Many times 
we are driving down the road 
and we hear a police siren. At 
the precise moment we hear the 
siren, we usually have some idea 
as to the direction it is coming 
from. We spend the next couple 


of seconds pin-pointing the exact 
location of the siren. How do we 
do this? 

In the latter 1900’s, Lord 
Rayleigh made observations 
about how humans localize 
sound. His findings and others 
have led to the theory that human 
localization is strongly dependent 
on Interaural Time Differences 
(ITD) and Interaural Level or 
Pressure Differences (ILD or 
IPD) for the horizontal listening 
plane and Spectral Cues on the 
vertical listening plane. 


INTERAURAL TIME 
DIFFERENCES 

ITD’s are the easiest of the 
directional cues that the 
human auditory system Sound 
uses to determine the Source 
placement of a 
sound. 





Observer 


FIGURE 1 


Figure | shows what happens to 
sound waves presented to the 
right side of a listener. 


The interaural time difference, as 
depicted in Figure 1, is the time 
between the dark sound wave 
reaching the listener and the 
lighter sound wave. It should be 
obvious that the dark sound 
wave will reach the right ear 
first. The difference in time 
accounts for the localization of 
the source to the right of the 
listener. If the sound source is 
placed exactly in front of the 
listener, each of the two sound 
waves will reach the left and 
right ears at the same time giving 
_an ITD of zero. The listener will 
perceive the sound directly in 
front. 


Now, in our virtual world, we 
could represent the placement of 
sound by just having a speaker at 
some particular location in space 
for each object. However, 
several problems occur with this 
idea. If there is more than one 
sound, we need a speaker for 
each one. If the user moves in 
the virtual world, so do the 
sounds therefore, the speakers 
would need to also move and this 
is obviously not very practical. 


Left Channel 


Observer 


Figure 2 


mae Channel 


The solution is to create the two 
different sound waves ourselves. 
By the way, this is exactly how 
stereo radio broadcasts are done. 
Figure 2 shows the typical stereo 
setup. 


In Figure 2, the listener hears the 
stereo sound at the same time 
from each of the speakers. This 
causes the auditory system to 
perceive the sound to be coming 
from directly in front of the 
listener. In sound localization 
terminology this would be 
position: elevation = 0 degrees, 
azimuth = 0 degrees, and dis- 
tance = unknown. Figure 3 
shows the relationship of these 
terms to the listener. 


Recall from Figure 1 that each 
sound source can actually be 
heard from each ear. So the 
correct representation for stereo 
hearing is shown in Figure 4. 


Each of the secondary sound 
waves to the opposite ear are 
canceled out by our auditory 
system. 


In several musical 
recordings, they play 
with the sound by 
moving from chan- 
nel to channel. At 
one instant, the 
sound is coming 
from the middle of 
the listening area 
and the next, the 
sound is coming 
from the right, then 
back to the left and 
finally back to the 
middle position. By 








Elevation 


Figure 3 


changing the interaural time 
difference from zero, to full 
right, to full left, and back to 
zero, we hear the music in 
different places. Notice how- 
ever, that we never hear the 
music beyond where the speakers 
are. We never hear the music 
from the positions azimuth 90 
degrees or from 270 degrees. 
The 90 degree position is where 
our right ear is and 270 degrees 
is where our left ear is located. 


Further research has shown that 
the frequency level of the sound 
source plays an important part in 
a person localizing a sound using 
interaural time differences. At 
high frequencies, the head of the 
listener creates a “shadow” effect 
on the sound waves thus weak- 
ening the effects of the ITD. The 
frequency cut off is somewhere 
around 4000 Hz. At low fre- 
quencies, <1000 Hz, ITDs are 
very effective. The frequencies 
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between 1000 and 4000 Hz tend 
to be listener specific as to the 
effects of ITD. For the low 
frequencies, the ITD 1s: 


3 * radius 
--- * sin (angle) 
speed of sound 





For high frequencies, the equa- 
tion becomes: 


2 * radius 
--- * sin (angle) 
speed of sound 


How are these equations used? 
We will consider the equation for 
low frequencies with a person 
whose head radius measures 9 
centimeters and the speed of 
sound as 343 meters per second. 
The equation becomes 


ITD = 0.052478 * sin ( angle ) 


If we place a sound source at an 
angle of incidence equal to 45 











Left Channel 


Observer 


Figure 4 


degrees to the right of the lis- 
tener, we would get an ITD 
value of 0.037107 seconds. 

This value tells us that there must 
be a interaural time difference of 
37.1 milliseconds between a 
sound wave reaching the left ear 
from the right ear. 


To produce this, we generate a 
sound in the right speaker and 
37.1 milliseconds later, generate 
the same sound in the left 


- speaker. The right speaker 











sound waves would 

reach the listener 
37.1 milliseconds 
before the left speaker 

waves. 
If we move the sound 

source to 45 degrees to the 
left of the listener, or 315 
degrees to the right, we would 
get the same value except nega- 
tive. Therefore, we can do the 
same as above but start with the 
left speaker first. 


In two additional pieces of 
literature, the ITD equations 
were slightly different. The first 


is from Woodworth (1938). The 
equation 1s stated as: 


ITD = Radius ( theta + sin (theta)) 


In Kendail and Rogers, the ITD 
equation 1s given as: 


ITD = .0008 sin ( theta ) 


The authors state that this equa- 


interaural Time Differences at Different Angles 
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CHART 1 
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From Kendall, Rogers, and Othe 


tion is an approximation derived 
from many different sources of 

actual interaural time difference 
measurements. 


Using data from Kendall and 
Rogers and various other 
sources, the plot in Chart lshows 
the interaural time differences in 
milliseconds for different azimuth 
angles. 


FRONT TO BACK 

You may have noticed that 
there is a slight problem. The 
sin of 45 degrees and 135 de- 
grees are the same. Therefore, if 
we wish to place a sound source 
at the front of the user at 45 
degrees to the right, we use a 
delay of 37.1 milliseconds. This 
is the same value used to place a 
sound at the back of the user at 
45 degrees to the right. Obvi- 
ously, this will not work cor- 


rectly. The solution to this and 
several other localization prob- 
lems, which we do not have 
enough room to discuss here, is 
to take into consideration pinna 
localization cues. We will 
discuss this shortly under the 
heading SPECTRAL CUES. 


Interaural Time Differences aid 
in the localization of sound on 
the horizontal plane for low 
frequencies. The ITDs are used 
for high frequencies but 
Interaural Pressure Differences 
are the primary localization cues. 


INTERAURAL PRESSURE 
DIFFERENCES 

Simply, interaural pressure 
differences is the difference in 
volume of the sound source. Ifa 
sound source is closer to one ear 
than the other, there will be a 
difference in the intensity of the 


CHART 2 


sound waves arriving at the 
closer ear. Our auditory system 
uses these differences to help in 
the localization process. Over 
the years, many different re- 
searchers have measured the 
pressures generated at the ears 
when a sound source is present. 


These findings show that the 
interaural pressure differences 
begin to effect our localization 
when the sound frequency 
reaches 3 kHz. Once the fre- 
quency of the source reaches 5 
kHz, the IPD are the primary 
localization cues. Using data 
from Kendall and Rogers and 
various other sources, we can 
plot the pressure differences for 
several frequencies. Charts 2 
and 3 show two difference 
frequencies. 


There is an obvious presence of 


interaural Presssure Differences for 6000 Hz 
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the interaural pressure differ- 
ences in the 6000 Hz range as 
opposed to the 500 Hz range. 


In Kendall and Rogers, they give 
an interaural pressure difference 
equation as: 


IPD = 1.0 + (Freq/1000)°* *sin(theta) 


where the frequency is given in 
kHz. 


Both interaural time difference 
and interaural pressure difference 
cues are used by our auditory 
system to localize sounds in the 
horizontal plane around our 
head. A different set of cues are 
used for the vertical plane. 


SPECTRAL CUES 

The major spectral cues for 
vertical plane localization are 
head scattering, torso scattering 
and the pinna, the outer part of 
the ear. When a sound hits any 
of these three body parts, it will 
be reflected and diffracted 
toward and away from the ear 


dB 


canal. Research over the last 
several years is just beginning to 
understand exactly how the pinna 
affects sound waves. In Blauert, 
a definition is given for the 
alterations that a sound source 
undergoes once tt hits the outer 
ear. This is an extremely com- 
plex equation that is not really 
worth reproducing here. A 
series of Fast Fourier Transforms 
are used to appropriately alter 
the original signal. This goes 
beyond the scope of this intro- 
duction to the theory of 3D 
sound. I direct you to any of the 
publications in the bibliography 
for a more detailed explanation 


of the pinna localization cues. 


All of these equations are good, 
but not as good as having hard 
data to generate the appropriate 





10 12 14 


Freguency (kHz) 
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Chart 4 
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three-dimensional cues needed 
for 3D sound. 


HEAD-RELATED 
TRANSFER FUNCTIONS 
Since the early 1900’s, scien- 
tists have done experiments on 
humans to determine how they 
localize sounds. Out of these 
experiments have come the head- 
related transfer functions. . Using 
small microphones inserted in the 
ears at the eardrums, scientists 
introduce sounds to the listener 
at precise angles. As the fre- 
quency of a sound changes, the 
microphones pick up changes in 
the original tone. The total 
change for a range of frequencies 
is called a transfer function. 
Chart 4 shows what a transfer 
function might look like. 


The solid black line would be for 
one ear and the other dash line 
would be for the other ear. This 
line graph shows how the ampli- 
tude of the sound source changes 
as the frequency changes. Each 
angular position around the head 
will have a different transfer 
function. Using these transfer 
functions, a system can be 
developed that accurately places 
sound around the user. 

This technique involves taking 
the desired position of the sound, 
azimuth, elevation, and distance. 
and filtering the signal using the 
transfer functions. This filtering 


is done by taking the original 
signal and convolving it with the 
transfer functions. Convolving a 
signal involves multiplying the 
Discrete Fourier Transform 
(DFT) of the original signal with 
the Discrete Fourier Transform 
of the transfer function. Figure 5 
shows an example of a convolu- 
tion of a DFT sample with a unit 
sample. 


This convolution had the effect 
of decreasing each of the original 
signal samples by one half. 


There is a tremendous amount of 
computation for a system that 
produces 3D sound in this 
manner. In the next article, we 
briefly talk about a product 
called the Convolvotron. This 
product produces 3D sound 
using digital filtering and head- 
related transfer functions. The 
system 1s able to handle the 
computations by using 128 
parallel processors especially 
designed for this task. 


Systems such as the 
Convolvotron work well to place 
3D sounds. However, each 
person has a different transfer 
function for each of the possible 
angular positions around the 
head. It would be ideal to take 
measurements for each person 
who wanted to use a Virtual 
Reality system with 3D sound in 
order to place the sound per- 
fectly for each person. However, 
this is not realistic, so the design- 
ers had to find a person who 
placed sound almost perfectly. 
The head-related transfer func- 
tions for this person would 


provide placement for most 
people using the system. 


CONCLUSION 

Over the last six pages, we 
looked at interaural time differ- 
ences, interaural pressure differ- 
ences, pinna cues, and head- 
related transfer functions. Each 
of these components are essential 
in order for the human auditory 
system to localize a sound. 
However, they are not the only 
cues. Research over the last 
couple of years has found many 
other cues that are used to 
localize sound. 


The concepts for reproducing 
three-dimensional sound are 
extremely mathematically ori- 
ented. In addition to this article, 
I would strongly recommend the 
two articles by Richard Moore 
listed in the bibliography which 
explain the fundamentals of 
digital signal processing. 


In the next article, we look at 
two commercial products that 
produce 3D sound. One of them 
is very expensive and the other is 
‘just’ expensive. The third article 
in our 3D sound theme looks at 
creating a simple 3D sound 
reproduction system using 
interaural time differences and 
two digital-to-analog 

converters. Ii 


BIBLIOGRAPHY 


Begault, Durand R. “Challenges 
to the Successful Implementation 
of 3-D Sound” Journal of the 
Audio Engineering Society. 
Vol.39, No.11, 1991: pp864- 


870. 


Blauert, J. “Spatial Hearing” 
MIT PRESS:1983. 


Blauert, J. “Sound Localization 
in the Median Plane.” Acustica. 
Vol.22 1969/1970: pp.205-213. 


Bosi, Marina. “An Interactive 
Real-time System for the Control 
of Sound Localization.” Com- 
puter Music Journal. Vol.14, 
No.4, 1990: pp.59-64. 


Cooper, Duane H. “Calculator 
Program for Head-Related 
Transfer Function’. Journal of 
the Audio Engineering Society. 
Vol. 30, No 1/2, 1982: pp34-38. 


Cooper, Duane H. “Letters to 
the Editor”. Journal of the Audio 
Engineering Society. Vol.31, 
No.10, 1983: pp760. 


Gatehouse, R. Wayne. ED. 
“Localization of Sound: Theory 
and Application.” AMPHORE 
Press: 1982. 


Kendall, Gary S., and C.A. 
Puddie Rodgers. “The Simula- 
tion of Three-Dimensional 
Localization Cues for Head- 
phone Listening.” Proceedings 
of the 1981 International Com- 
puter Music Conference. 1981: 
pp.225-243. 


Kuhn, George F. “Model for the 
Interaural Time Differences in 
the Azimuthal Plane.” Journal of 
the Acoustical Society of 
America. Vol.62, No.1, 1977: 
pp. 157-167. 


Issue #6 November/December, 1992 PCVR {| 


Moore, F. Richard. “A General 
Model for Spatial Processing of 
Sounds.” Computer Music 
Journal. Vol.7, No.3, 1983: 
pp.6-15. 


Moore, F. R. “An Introduction 
to the Mathematics of Digitial 
Signal Processing. Part I.” 
Computer Music Journal. Vol. II, 
No.1, pp.38-47. 


Moore, F. R. “An Introduction 
to the Mathematics of Digitial 
Signal Processing. Part II.” 
Computer Music Journal. Vol. I, 
No.2, pp.38-60. 


Sakamoto, Naraji, Toshiyuki 
Gotoh, Takuyo Kogure, 
Masatoshi Shimbo, Almon H. 
Clegg. “Controlling Sound- 
Image Localization in Stereo- 
phonic Reproduction.” Journal 
of the Audio Engineering Soci- 
ety. Vol.29, No.11, 1981: 

pp. 794-798. 


Sakamoto, Naraji, Toshiyuki 
Gotoh, Takuyo Kogure, 
Masatoshi Shimbo, Almon H. 
Clegg. “Controlling Sound- 
Image Localization in Stereo- 
phonic Reproduction:Part II.” 
Journal of the Audio Engineering 
Society. Vol.30, No.10, 1982: 
pp.719-721. 


Shaw, E. A. G. “Transformation 
of Sound Pressure Level From 
the Free Field to the Eardrum in 
the Horizontal Plane.” Journal 
of the Acoustical Society of 
America. Vol.56, No.6, 
1974:pp. 1848-1861. 


Stockham, Thomas G. “High- 


12 Issue #6 November/December, 1992 PCVR 


Speed Convolution and Correla- 
tion.” Proceedings of the Spring 
Joint Computer Conference. 
1966: pp.229-232. 


Ward, Wayne Hinson. “A Signal 
Processing Mmodel of Auditory 
Lateralization” Thesis University 
of Colorado, Boulder, Colorado. 
1984. 


Wenzel, Elizabeth M., Frederic 
L. Wightman, Scott H. Foster. 
“A Virtual Display System 

For Conveying Three-Dimen- 
sional Acoustic Information.” 
Proceedings of the Human 
Factors Society. 1988: pp86-90. 


Wenzel, Elizabeth M., Frederic 
L. Wightman, and Doris J. 
Kistler. “Localization with Non- 
individualized Virtual Acoustic 
Display Cues.” 


Wightman, Frederic L., and 


Doris J. Kistler. “Headphone 


Simulation of Free-Field 
Listening. I:Stimulus Synthesis.” 


Journal of the Acoustical Society 
of America. Vol.85, No.2, 1989: 


pp.858-867. 


Wightman, Frederic L., and 
Doris J. Kistler. “Headphone 
Simulation of Free-Field 
Listening. II:Psychophysical 
Validation.” Journal of the 
Acoustical Society of America. 
Vol.85, No.2, 1989: pp.868-878. 


Yost, William A., and George 
Gourevitch. “Directonal Hear- 
ing” Springer-Verlag: 1987. 


Joseph D. Gradecki is the pub- 
lisher of PCVR. Since being 
introduced to VIrtual Reality by 
a couple of friends, he has 
dedicated himself to this growing 
technology. 


3D 
Sound 


Products 


Joseph D. Gradecki 


We need real 
products to 
incorporate 3D 
sound into our 
worlds. Two 
products are. 
currently on the 
market 

that provide true 
3D sound 
reproduction. 





Na, that we know the theory 
behind three dimensional sound 
projection, we need to look at 
the products that are currently 
available for 3D sound produc- 
tion. Research shows that there 
are two products on the market 
that create sound anywhere 
around a users head, they are 
Focal Point 3D Audio from 
Focal Point and the 
Convolvotron from Crystal River 
Engineering, Inc. 


FOCAL POINT 

There are two versions of this 
system available; one for the 
Macintosh and one for the IBM 
PC. A price for the PC version 
was not available at press time 
but the Macintosh version costs 
$1795.00 for a single channel of 
audio. 


The Macintosh version of the 
system convolves any audio 
signal with head-related transfer 
functions to generate output for 
the left and right ears. The 
system consists of a specially 
modified Digidesign 
Audiomedia/FP card for each 
channel. The audio produced is 
CD quality at 44.1 kHz froma 
16-bit digital-to-analog con- 
verter. The system is pro- 
grammed using Think C and a set 
of library functions. 


The PC version is a specifically 
engineered audio card including a 
dedicated Digital Signal Process- 
ing chip. The card can position 
two separate sounds in real time. 
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CONVOLVOTRON 

The Convolvotron is the pre- 
mier 3D sound audio card. A 
four input channel system costs 
$14,995.00 and requires two PC 
card slots. The Convolvotron 
was produced by the original 
NASA 3D sound investigators. 
The system is programmed using 
Microsoft C calls to a library. 
What makes this card so expen- 
sive is its parallel nature. Instead 
of a single Digital Signal Pro- 
cessing chip, there is a chipset 
which contains 128 parallel 
multiply/accumulate/shift proces- 
SOrs. 


Sound is sampled and generated 
at CD quality using a total of 
four 16-bit synchronized analog- 
to-digital and two 16-bit syn- 
chronized digital-to-analog 
converters. The system has a 
peak convolution speed of 320 
million multiply/accumulate/shift 
operations per second. 


Each of the four inputs are 
sampled, filtered with time- 
varying filters which take into 
consideration a moving head and 
a moving sound source, and 
produced at a rate of 50 kHz. 


CONCLUSION 

Either of these systems would 
give us the 3D sound processing 
that we need to incorporate an 
additional level of realism in our 
virtual world. However, both of 
them are outside the reach of 
most experimenters. In the next 
article, we discuss the construc- 
tion of a simple 3D sound system 
for our own use. tk 
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| Joseph D. Gradecki | 


/A 3D sound 
| system can be built | 
for under $25.00 
and allow us to 
experiment with 
3D sound. 


The system pro- 


| vides placement of 
| a Single sound 


source in the front 
horizontal plane. 
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N.. that we have a little 


knowledge of the theory of 3D 
sound, we need to build a system 
that will allow us to experiment 
with this technology. The system 
we are going to build consists of 
two digital-to-analog converters 
and software. The software will 
present a tone and move it from 
the far left to the far right. The 
system can be used with speakers 
and/or headphones. 


CIRCUIT 

The circuit for the 3D sound 
system is similar to the circuit we 
used for the head mounted 
display and head tracker in issue 
5. The first part is to build the 
interface to the computer. Fig- 
ure 1 shows the interface. 


This interface to the computer 
can be programmed to use any of 


_ eight different I/O ports simply 


by connecting pin 6 of the 8255 
chip to the appropriate pin of the 
74LS138. If the pin selected is 
12, the 8255 will be located at 
the memory locations, decimal 
608-611. 


Location 608 = Port A 
Location 609 = Port B 
Location 610 = Port C 
Location 611 = Control 


Programming the 8255 is straight 
forward. Since we are going 
from a digital signal to analog, 
we want the ports of the 8255 to 
be output only. This is done by 
setting the control port to a 
decimal value of 128. In Turbo 
Pascal, this would be: 

port[611] := 128; 


and in C: 
outportb[611] = 128; 


To output a value to one of the 
ports, you assign a value to a 
port using the two commands 
shown above. For example, to 
output the value 64 to port A, 
the commands would be: 


port[6038] := 64; 
or 
outportb[608]| = 64; 


D/A 

The next step is to interface the 
digital-to-analog converters to 
the 8255. The circuit for one D/ 
A is shown in figure 2. 


The eight data lines are con- 
nected to port A of the 8255. A 
second circuit like the example 
above is constructed for port B. 
This gives us two channels for 
sound. 


The output of each 741 op-amp 
is connected to a stereo amplifier 
or portable radio. Although 
optional, a headphone jack and a 
set of headphones will be useful 
when using the demonstration 
program. 


The circuit uses both +5 and -5 
for voltages. The -5S voltage is 
available at pin BS on the PC 
bus. 


SOFTWARE 

The second half of the project is 
the software. The purpose of the 
software driver for this kit 1s to 
take a tone and move it from 
your left ear to your right ear. 
We use two procedures called 


#4L$138 


all — 
azd ° 
az2 


IBM Bus 


az6 
a25 
a24 


play_note and play_note?2 to play 
a note through the digital-to- 
analog converters. The proce- 
dures look like: 


procedure play_note ( note : longint; volume, 
angle : integer ); 
var i,k,a,j : integer; 
freq : longint; 
begin 
fori:=1to50do { Length ) 
begin 
port[608] := volume; 
for j := 1 to angle do 
a:= j; 
port[609] := volume; 
for k := 1 to note-angle do 
a:=k; 
port[608] := 0; 
for k := 1 to note-(note-angle) do 
a:=k; 
port[609] := 0; 
for k := 1 to note-angle do 
a :=k; 
end; 
delay ( 1000 ); 


end; 


Three parameters are sent to this 
procedure. The first called note 
is the number of cycles that a 
note requires to achieve its 
frequency. A number of notes 
and their cycles are given as 
constants in the program. The 
second parameter called volume 
determines how loud the note 
will be heard. The third called 
angle is the amount of delay time 
amount for the 3D sound effects. 





0x200 
0x220 
0x240 
0x260 
0x280 
0x2 A0 
0x2 CO 
0x2E0 


IBM Bus 


FIGURE 1 


A sound is played through a 
digital-to-analog converter by 
assigning the volume value to the 
DAC, looping the desired num- 
ber of cycles, turning the DAC 
off by presenting a zero to it, and 
looping the desired number of 
cycles again. To slow things 
down, we introduce a second 
delay between notes. 


The two procedures differ in that 
play_note will always fire the 
DAC at location 608 before the 
DAC at 609. The procedure 
play_note2 does the opposite. 
To move a tone from the left ear 
to the center space between the 





BO 


Port B 


Port A 


Al 


ears, a delay must be introduced 
between the time a tone is sent to 
the left ear and the right. Each 
of the procedures have loop 
delays that first introduce the 
sound to the appropriate ear and 
delay the required time. The 
tone is then introduced to the 
second ear. Since the original 
tone must end first, we loop the 
tone time minus the delay time. 
At this point, we turn off the first 
DAC. We then loop the remain- 
ing time for the second DAC and 
then turn it off. Different delay 
times cause the tone to be heard 
at different places. The code for 
the left part of this movement is: 


If 
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DACO800 


150, 3700 ); 
150, 3500 ); 
150, 3000 ); 
150, 2500 ); 
150, 2000 ); 
150, 1500 ); 
150, 1000 ); 
150, 500 ); 
150, 250); 
150, 0); 


play_note2 ( mide, 
play_note2 ( midc, 
play_note2 ( mide, 
play_note2 ( midc, 
play_note2 ( midc, 
play_note2 ( midc, 
play_note2 ( midc, 
play_note2 ( midc, 
play_note2 ( midc, 


play_note2 ( mide, 


The first delay is the longest. It 
introduces the sound to the left 
ear long before the right ear. 
This causes our auditory system 
to locate the sound from the left 
only. As we decrease the delay 
values, the sound moves to the 
front. When the delay is 0, both 
ears hear the tone at the same 
time. To move the sound to the 
right, the following calls are 
made: 


150, 0); 
150, 250 ); 
150, 500 ); 
150, 1000 ); 
150, 1500 ); 
150, 2000 ); 
150, 2500 ); 
150, 3000 ); 
150, 3500 ); 
150, 3700 ); 


play_note ( mide, 
play_note ( mide, 
play_note ( midc, 
play_note ( mide, 
play_note ( midc, 
play_note ( mide, 
play_note ( mide, 
play_note ( mide, 
play_note ( mide, 
play_note ( midc, 


Note that the different proce- 
dures are used. When executing 
this program at home, you may 
have to play with the delays. 
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Output 





FIGURE 2 


This program was created ona 
50-Mhz 80486. Slower ma- 
chines will need proportionally 
decreased delays. 


THEORY 

You may be wondering why I 
didn’t use the equations from the 
3D Sound Theory article. The 
reason is most pieces of literature 


~ estimated the delay values at 2 or 


3. I wanted to create something 
that would smoothly move the 
tone from side to side and the 
estimates in the first artcle did 
not work. The second reason is 
when I actually programmed the 
equations, time was lost in the 
calculations. Since I intend to 
include 3D sound in a new 
rendering package, I wanted it as 
fast as possible. I can achieve 
the optimal speed by converting 
the above code to assembly 
language and optimizing it. 


HEADPHONES 

You can listen to the tone two 
different ways. The first is to set 
up two speakers. One speaker 
should be to the far left and one 


to the far right of you. This 
gives the best results. I did an 
experiment using a boom box 
with the speaker eight inches 
apart and it worked, but was 
difficult to follow the tone. 


When it comes to headphones, 
it’s an entirely different problem. 
Sound localization in headphones 
is called lateralization. To 
experience the difference, plug in 
a pair of headphones to your amp 
and run the demo program again. 
You should hear the tone moving 
across the inside of your head. 
The reason for this is we are not 
taking into consideration the 
effects the pinnae has on the 
sound. In order to do this, we 
must represent the transfer 
function of the outer ear. Unfor- 
tunately we cannot, because we 
do not have the transfer finc- 
tions. Obtaining these transfer 
functions would entail extensive 
monitoring using in-ear micro- 
phones which we do not have at 
our disposal. 


CONCLUSION 

Using two digital-to-analog 
converters and a very simple 
program, we have simulated a 
tone moving from the left side of 
our head to the right. While we 
cannot place sounds outside the 
front half of the horizontal plane, 
the computations involved are 
simple and not very 
computationally intensive. This 
system can be used in a virtual 
world by giving sound to objects 
that are in front of us. Ii 


The Powerglove 


Serial Interface: 


Touching The 


Future 





Jim Brain 


Ben Gross 


The PGSI inter- 
faces the Mattel 
Powerglove to the 
serial port of any 
computer system. 


By providing-a 
standard interface 


to the host CPU, the 
PGSI allows users 
to port code to dif- 
ferent machines 


with a minimum of 


| rewriting. 





E., anyone even remotely 
associated with the fledgling field 
of virtual reality, the costs of 
gearing up for VR experiments 
or studies can prove overpower- 
ing and even prohibitive. All 
over the world, interested indi- 
viduals are searching for low- 
cost alternative devices capable 
enough for beginning experi- 
ments in the field. For some 
time, one such device has been 
the Mattel+ PowerGlovet, 
manufactured for the Nintendo 
Entertainment System+ (NES). 
This device provides a low cost 
substitute for the more powerful 
Polhemus+ Fastrak+ and the 
VPL+ DataGlove+ combination. 
For many, this glove had the 
power necessary for “tinkering 
around” in early experiments, but 
lacked one important item: a 
standard interface. Since the 
glove was designed for the NES, 
it used a non-standard 7 pin 
connector, and the protocol is a 
modified synchronous serial 
transfer. This has reduced its use 
in low-cost VR. 


The non-standard PowerGlovet+ 
connector has not been as much 
a hindrance as the modified serial 
protocol, since the latter requires 
special software to perform the 
protocol emulation, whereas the 
former can be eliminated by 
replacing the connector. AI- 
though these problems plagued 
its widespread use, many inter- 
ested individuals set out and 
developed workarounds to the 
protocol problem. When the 
Curtis Nintendo+ Super Extendo 
Cables, now manufactured by 


Nuby Manufacturing, arrived on 
the scene, the connector problem 
diminished. Now that the proto- 
col alone prevented operation of 
the glove, those who developed 
adapters took two related ap- 
proaches to provide the solution. 


Many early users of the glove 
hooked the unit up to appropri- 
ate input/output pins on personal 
computers, and wrote protocol 
emulation routines on the host 
system to poll the glove for 
input. Early examples include 
various parallel port hookups for 
the Amigat+, IBM+, and Atari 
ST+ computer systems. This 
approach has two flaws. First, 
the interface 1s not sold commer- 
cially, so users were expected to 
build the interface themselves, or 
have someone build it for them. 
Second, since correct operation 
depends on protocol conversion 
and polling, each CPU and/or 
operating system change required 
a new piece of software to 
perform the required actions. 
This inhibited development. 
Also, this second restriction 
usually only allows operation on 
computer/operating system 
combinations that allowed the 
user access to hardware input/ 
output. This made operation on 
high powered workstations 
extremely difficult (but not 
impossible). 


Many people have seen the need 
for a standard interface between 
the PowerGlove+ and the host 
CPU. Examples of this second 
approach include the GoldBrick+ 
interface and the original 
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PowerGlove+ Serial 
Adapter(PGSA+) from AGE, 
Inc. These devices provided a 
level of abstraction between the 
user and the glove, and the 
PGSA allowed any computer 
system with a standard RS-232 
port to utilize the glove. The 
GoldBrick interface was tailored 
to operate on the Apple Desktop 
Bus (ADB+) found on Macin- 
tosh style computers, while the 
PGSA worked on standard RS- 
232 ports. This hardware ap- 
proach is the category that the 
PowerGlove+ Serial Interface 
(PGSI) falls into. By providing a 
standard interface to the host 
CPU, the PGSI allows users to 
port code to different machines 
with a minimum of rewriting. 


The main fault of the 
PowerGlove+ Serial Adapter is 
that very few were ever pro- 
duced. Although the design is 
still being manufactured, it is 
time for a new contender in the 
race to bring Virtual Reality 
devices to those who need them. 


The Student Chapter of the 
Association for Computing 
Machinery at the University of 
Illinois at Urbana, Champaign is 
currently developing the 
PowerGlovet+ Serial Interface 
(PGSI) as the next step in low- 
cost interface technology. Spe- 
cifically, the Special Interest 
Group in Computer Architecture 
is developing the unit as a 
fundraising project to aid in the 
purchase of integrated circuits 
and test equipment to develop 
more projects like this one. Jim 
Brain and Ben Gross head up the 
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design team that has worked on 
the project from early in Febru- 
ary 1992 to the present. 


Why attempt such a product? 
The project was suggested to 
ACM at UIUC by assistant 
professor Gregory Newby of the 
Library and Information Sciences 
Department. Newby, as a 
graduate student at Syracuse 
University, became interested in 
the work of the creators of the 
PGSA, AGE Inc. AGE, Inc., 
which stands for Abrams-Gentile 
Entertainment, had sold the 
rights to the design of the 
PowerGlove to Mattel Toys, 
Inc., and had designed an inter- 
face that would allow anyone 
with a standard RS-232 compli- 
ant computer to access the glove. 
When Newby took his post at the 
University of Illinois, he brought 
along the box and permission 
from AGE to make more if he 


wanted to. Greg, upon realizing 


the complexity of the device, 
found ACM at UIUC willing to 
help him out in developing a 
replacement for the interface as a 
fund-raiser. Along the way, it 
became easier to develop a new 
interface rather than reverse- 
engineer the old one, and the 
PGSI was born. 


What makes up the product? 
The unit itself, while measuring 
only 1"x1.5"x3.35" and resem- 
bling a elongated gender 
changer, houses a complete 
Motorolat MC68HC11E2FN 
(HC11) imbedded 
microcontroller, associated 
support circuitry, and appropri- 
ate interface connectors. Since 


the unit employs a microproces- 
sor to enable operation, the 
device has a rich set of com- 
mands and can be configured for 
a variety of uses. The heart of 
the system, an HC11 processor, 
has 2048 bytes of Electrically 
Erasable Programmable Read 
Only Memory (EEPROM) and 
256 bytes of Random Access 
memory (RAM). The EEPROM 
allows the control program to be 
located on-chip, and the unique 
properties of the EEPROM allow 
end users to upgrade the control 
program themselves, without 
needing to ship the unit back to 
ACM at UIUC for upgrading. 
Lest one think otherwise, the 
entire program fits very nicely in 
2K or EEPROM, and 256 bytes 
of RAM is more than adequate 
for all temporary storage. 


How does it work? 

As with all microcontrollers, the. 
HC11 has 40 various input/ 
output pins. The Mattel+ 
PowerGlove+ connects up to the 
microcontroller via these I/O 
pins, and a control program 
stored in EEPROM (firmware) 
controls the state of those pins or 
reads their value at appropriate 
times. The end user sends a 
special one byte command to the 
PGSI through the serial port 
requesting PowerGlove+ infor- 
mation, and the firmware parses 
that command and returns a 
packet of information. This 
packet, sent to the host CPU via 
serial transfer, contains all the 
information available from the 
PowerGlove. The end user 1s 
completely unaware of the 
necessary protocol conversion 


=“ 


and does not need to poll the 
glove when it is not needed. The 
polling command is only one of 
many that can be interpreted by 
the firmware. This makes the 
device very functional. 


Can I use it with existing 
software? 

Well, to be truthful, there exists 
few software titles which use the 
PowerGlove+ with any adapter. 
However, the designers, knowing 
full well that compatibility is a 
major concern in any new prod- 
uct, have made every attempt to 
provide various emulation modes 
in the PGSI. Since the device is 
a derivative of the AGE PGSA 
(and was called the PGSA II 
while in early development), the 
PGSI includes full compatibility 
with production versions of the 
PGSA. Also, since the device 
borrows code and design from a 
home-brew adapter by Ron 
Menelli (available via FTP file 
transfer), complete compatibility 
with the Menelli design has been 
provided. Since the interface 
must juggle two complete emula- 
tion modes, a few assumptions 
have been made on the initial 
behavior of the calling program, 
like proper initialization of the 
device. Also, since both of these 
early designs did not include any 
provisions for more than one set 
of commands, the PGSI will 
autoset the emulation mode. It 
can do this easily because the 
command sets are completely 
different. Thus, certain com- 
mands imply a particular emula- 
tion mode. 


Does it perform all of the 


functions available in these 
earlier devices? 

Yes, and more. When the PGSI 
was in early development, many 
people expressed an interest in 
having one device that could 
control both the PowerGlovet+ 
and a pair of SEGA+ style 3-D 
shutter glasses, also known as 
field sequential vision glasses. 
These glasses have two LCD 
‘light valves’, one for each eye, 
that control the passage of light 
into the respective eye. By using 
the glasses and a computer 
monitor, it is possible to create 
the illusion of stereoscopic 
vision. Although the technique is 
straightforward, it warrants a 
passing discussion here. First, 
draw two pictures, one of the 
object(s) as seen through only 
the left eye, and the other as seen 
through only the right eye. Next, 
display the left eye image on the 
computer monitor and let the left 
eye (and only the left eye) view 
it. Next display the right eye 
image and allow the right eye to 
view it. Repeat this display 
sequence (left,right) continuously 
and in rapid succession, and the 
human eye will, with the aid of 
the glasses, merge the two 2-D 
images into one 3-D image. This 
is stereoscopic vision. The PGSI 
will allow the connection of one 
set of 3-D glasses for the pur- 
pose of providing stereoscopic 
vision, and the glasses can be 
controlled through either firm- 
ware commands or by controlling 
specific I/O pins on the host CPU 
directly. 


Is that all there is? 
Well, this isn’t a Ginsut+ com- 


mercial, but there are many more 
functions available on the PGSI. 
The HC11 contains eight 8-bit 
linear Analog-to-Digital convert- 
ers, So the PGSI includes the 
capability to wire those inputs to 
any outside device and read the 
values through software. AI- 
though this has not been tested, 
it should be possible to use the 
A/D ports to read the finger flex 
positions with 8 bits of resolution 
per finger. The PGSI also has 8 
digital inputs and 8 digital out- 
puts that can be accessed 
through software. All these 
features are included in the 
Post 


Is it currently available? 
Unfortunately, No. A number 
of problems have plagued the 
release of the PGSI. Most 
notably, the fact that it is a 
student project means that 
resources are allocated to it 
sporadically, corresponding to 
those times when no homework, 
exams or projects must be 
completed. Another involves 
legalities. As you probably 
know, universities cannot sell 
items for profit, and the National 
Association for Computing 
Machinery is classified as a not- 
for-profit organization. Al- 
though ACM at UIUC has 
already stated that profits from 
the sale of the PGSI will be used 
for purchase of equipment and 
supplies for the Special Interest 
Group (SIG) developing the 
PGSI, legal problems still exist. 
ACM at UIUC hopes to resolve 
the conflicts before the end of 
1992, but has assumed a conser- 
vative stance and set a shipping 
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date of first quarter 1993. At 
present count, 150 people have 
expressed an interest in purchas- 
ing a device, so a definite con- 
cern exists over the ability to 
effectively market the product as 
early as possible. 


How much will it cost ? 

The PGSI in assembled form 
will cost $95.00 plus tax for 
those people purchasing in 
Illinois and not being part of a 
tax exempt institution. A kit 
form will be available for $80.00. 
While that may seem a little high, 
ACM at UIUC does not make 
much profit at this price, since 
most of the cost is in mass- 
producing the unit, which ACM 
at UIUC will not do. Prospec- 
tive buyers are encouraged to 
compare this price with other 
products on the market and those 
not available yet. We are confi- 
dent that the PGSI represents the 
best buy for overall functionality. 


How does it hook up ? 

The PowerGlove+ Serial 
Interface connects to any per- 
sonal computer or workstation 
with an EIA-232D standard (RS- 
232) serial communications port 
capable of 9600 bps at no parity 
and | stop bit (9600,N,8, 1) 
available as a 25 pin DB-2S style 
connector. For those users with 
a newer style IBM or IBM 
compatible system that has a 9 
pin DB-9 connector, adapters 
can be readily purchased from 
computer stores or purchased 
with the PGSI. For those with a 
newer Apple Macintosh+ sys- 
tems with a mini-DIN connector 
for serial communications, an 
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adapter can be purchased from 
local computer stores or with the 
PGSI. As a general rule, any 
computer that can communicate 
with a standard external modem 
will work with the PGSI, so tests 
can be performed before pur- 
chase to ensure compatibility. 


TECHNICAL DESCRIPTION 
AND SPECIFICATIONS 

The PowerGlove+ Serial 
Interface represents an entire 
year of code generation, debug- 
ging, and compaction. While it is 
beyond the scope of the article 
(and possibly the scope of the 
authors) to discuss the protocol 
used by the PowerGlovet, below 
is a list of technical specifications 
on the PGSI. Readers are 
encouraged to email the authors 
for the FTP site of the complete 
(thus far) PGSI User/Program- 
mer Manual. If access to the 


_ Internet is unavailable, the 


manual may be obtained by 
mailing a self addressed, stamped 
manila envelope with enough 
postage for the 44 sheet manual 
and $2.00, to cover the cost of 
printing and mailing, to the 
address following this article. All 
purchasers of the PGSI will 
receive the latest edition of this 
document with their purchase. 


The PGSI contains 35 commands 
in the complete command set. 
This includes those commands 
required for complete AGE and 
Menelli emulation (differences 
are explained below), as well as 
superset commands found only in 
the PGSI. Since the majority of 
commands are self explanatory, 
this article will devote space to 








those commands essential to 
basic operation. The complete 
command set is shown in Table | 
and contains basic information 
about each command. To 
operate the PGSI, the user/ 
programmer need only be con- 
cerned with commands 0x07, 
Ox01, 0x02, or 0x07, 0x43, 
0x52, and Ox3F. The remainder 
of command sequences simply 
initiate extended features or 
access various filters. 


To understand the complexity of 
the PGSI design and appreciate 
the relatively few commands 
needed to operate the unit, it is 
necessary to examine the features 
the PGSI provides. One of the 
most basic of features is the 
ability to emulate either the 
original AGE PGSA interface or 
the newer Menelli device. ‘This 
means that the PGSI must not 
only transmit information in the 
correct sequence, but must also 
accept all commands for that 
emulation and switch emulation 
modes transparently. Informa- 
tion is transmitted in packets, 
which contain all pertinent 
information about the glove 
normally transmitted by the 
respective emulation mode. 
Table 2 describes the packet 
structure for the AGE emulation, 
while Table 3 shows Menelli 
packet structure. Notice that 
both tables describe complete 
packet structures with all ex- 
tended features enabled. Ini- 
tially, the AGE packet only 
contains bytes 00-10, whereas 
the Menelli packet contains bytes 
00-05 with a pre-packet header 
byte, OxAO, sent as the first byte 


in continuous mode as a delim- 
iter. 


In addition to providing two 
separate packet structures, the 
PGSI must relay information to 
the host CPU in one of two 
ways. The first, continuous 
mode, instructs the PGSI to send 
a new packet of information to 
the host CPU as soon as it 1s 
received from the glove. The 
second, request mode, instructs 
the PGSI to send a new packet 
upon reception of a send packet 
command. Packets are not 
stored, so the packet received is 
always the newest. This packet 
structure ensures that all relevant 
information about the glove is 
transmitted and provides the 
user/programmer with an easy 
way to gather data from the 
glove 


Even though the PGSI provides 
two complete emulation modes, 
they are by no means mutually 
exclusive. Notice that most 
commands can be accessed from 
either mode. This allows users in 
one emulation to access the filter 
commands in either emulation. If 
a user attempts to access a 
command from one emulation 
mode that is only available in the 
other emulation mode, the 
firmware will automatically 
accept the command and switch 
emulations. This means a user 
can put the PGSI in Menelli 
request mode with ‘R’ and turn 
the rotation filter on with 0x08. 


OPERATION OF THE PGSI 
To request a packet of informa- 
tion from the PGSI, one must 


first determine which mode to 
use in a program. Programmers 
of new applications are strongly 
encouraged to use the AGE 
emulation mode, since this mode 
provides more complete informa- 
tion about the glove and contains 
more commands. Menelli mode 
is mainly intended for those 
applications previously written 
and for users wishing to access 
the PGSI using standard text 
commands. 


Once the emulation mode is 
determined, the programmer 
must determine which type of 
data the program needs: continu- 
ous or request. Programs that 
track the hand in very tight loops 
benefit from the continuous 
output of data, while systems 
that only approach real time may 
benefit from the request mode. 
Currently, the glove will only 
update 27 times a second, so 
frequency of update is a major 
concern. 


The programmer now needs only 
to include the function libraries 
from the PGSI developer’s 
library, which includes all the 
basic driver routines as C- 
callable functions. If the pro- 
grammer has decided on AGE 
request, just send 0x07, 0x02. 
This not only turns on request 
mode, but sends a packet of 
information, as per the AGE 
emulation. The device will now 
send a new packet when in- 
structed by sending the 0x02 
command again. If the program- 
mer needs AGE continuous 
mode, 0x07, 0x01 will put the 
PGSI in that mode. Menelli 


request is 0x07, 0x52, and the 
packet is accessed with Ox3F. 
Note that, unlike the AGE 
request option, Meneili request 
does not automatically send a 
packet when the device 1s put 
into request mode. This is due to 
command differences. AGE 
combined the features of 0x52 
and Ox3F into one command, 
Ox02. Finally, Menelli continu- 
ous is 0x07, 0x43. These com- 
mand sequences illustrate the 
relative ease of using this prod- 
uct to acquire data from the 
PowerGlovet. 


If the application requires or will 
benefit from use of the LCD 
shutter glasses, it can control the 
glasses in one of three ways. The 
first two involve direct hardware 
I/O accesses, while the third can 
control the glasses via serially 
transmitted commands. Inthe 
first mode, the DTR and RTS 
lines on the serial port are used 
to control each lens individually. 
The second mode allows flipping 
between lenses with just one of 
those lines, meaning that the user 
can have left lens on : right lens 
off or vice versa. This mode is 
intended for Macintosh users 
who wish to control the glasses 
via hardware, but have access to 
only one digital output pin. The 
third mode uses commands sent 
over the serial connection to 
control the lenses. This ap- 
proach suffers slightly in speed 
comparisons, but can be used on 
all computer systems, regardless 
of hardware accessibility. 


Since the development of the 
PGSI is mostly complete, ACM 
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at UIUC is currently gearing up 
for other projects. Adapters to 
allow PGSI operation on MIDI 
and parallel ports is being consid- 
ered, as are projects intended to 
bring other low-cost VR devices 
to the public. As always, care 
will be taken to manufacture only 
top-quality products and soft- 
ware, since everyone has an eye 
on this project. 


While the space in this article is 
insufficient to give the reader a 
complete understanding of the 
PowerGlove+ Serial Interface, 
This article should familiarize the 
reader with the immense poten- 
tial of the unit. ACM at UIUC 
encourages input on any area of 
concern about this project. Rest 
assured that every attempt has 
been made to present a profes- 
sional looking and working 
product to those who find it 
useful in their work. 


For more information on the 
PowerGlove+ Serial Interface or 
any facet of its development, 
readers are encouraged to write 
to the following address with 
specific questions. We are 
always happy to answer ques- 
tions about this innovative 
product. We hope that this 
article provided a balance of 
information about the develop- 
ment and technical aspect of the 
PGSI, as well as spark interest in 
using this device in future prod- 
ucts and experiments. | 
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- PGSI Project Leader 
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Command Code Command Code Description Emulation Available = in 
(in HEX) (in ASCID 


0x01 


> 
Q2 
tr 


Place interface in continuous mode 


Place interface in request mode/request packet 


> 
Q 
tr 


0x02 


0x04 Resend default initialization packet to the PowerGlove AGE/Menelli 


none not implemented 
none not implemented 


Reset PowerGloveO and PGSI to default configuration AGE/Menell1 


0x05 


0x06 


0x07 


0x08 none Tum rotation filter on AGE/Menelli 


0x09 Tum rotation filter off AGE/Menelli 


Ox0A Tum PowerGloveO on for input AGE/Menelli 


Ox0B none Tum PowerGloveO off for input AGE/Menelli 


= il nnd RRS cco 
a 


t 
none Tum on digital inputs AGE/Menelli 


0x0C 


0Ox0OD 


OxOE 


| OxOF a C off digital inputs AGE/Menelli 


0x10 oro een Turn on first 4 channels of A/D AGE/Menelli 
Oxl1l pape Tum off first 4 channels of A/D AGE/Menell: 


| Tum on second 4 channels of A/D AGE/Menelli 
none 





| 7 * ——~ Tum off end 4 peers of A/D 2 AGE/Menelli 
| Ox 14 a a ee. ie uel Tum left lens dark, ledee right lens in current. state AGE/Men . | i 
Ox15 | fone Turn left lens clear, leave right lens in current state AGE/Menelli 
oer Tum right lens dark, leave left lens in current. state GE/Menelli | 
pede a Tur right lens clear, leave left lens in current state 


0x18 none Tum both lenses dark AGE/Menelli 





=} 
1°) 
+) 
a 


0x16 





| Ox17 AGE/Menell1 


0x19 feome both lenses clear AGE/Menell 
oe rea 
a Cc aoa 


Ox1C,0x01-0x08 none Change baud rate to value specified after command byte | AGE/Menelli 


> 
~ 
G 

tr 


| Ox1D | none Change chopping frequency of LCD lens driver circuitry, AGE/Menellh 


range: 16Hz to 5kHz. 


Ox1E,Ox00-OxFF none Send digital data to output port (Second byte is value to 


send) 


4 





> > 
co a 
“ a 
23 Ty} 
~ Ss 
=< = 
CG GQ 
4 = 
> O fey 


Ox2B a Tum  hysterisis deglitching ~— on 7E 
Ox2D a Tum — hysterisis — deglitching ~—o ff AGE/Menellh 


Ox3F Request a packet im Menelli emulation Menelli 


0x43 


i 
4 


Place wmterface im continuous mode Mienells 


ae 


> 
x 
to 
i 
| 


Place mterface m= request mode Menells 


Table 1 - Complete Command Set 
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Position in Packet Name Description Range 


Header Signals Start of Packet Ox5F 
i Start of 


Ss) 
I 


Y-direction reading -128 to 
Z Z-direction reading -128 to 127 


Rotation Gives rotation value in 30 degree increments 


Fires Gives position of thumb and first three fingers 0-3;0-3;0-3;0-3 


\ | 
} ] 
1 
i! 
14) 
nl 
{ 9 
| 
| 
Sty 


ce eeeaes ee Os 

a CES 

c SSeeeea CCL LE (eee ee aS CSE ema 
cineca eel: MIUARARSASHl EASE SeuMANReNA 
a CE 
Le AC 
i TS OR TE I eT RST SIREN 
CC CC 
a CC CC 
CE 


Table 2 - Packet Description in AGE Emulation/both modes 


ae. Seon Header Signals Start of Packet 
i © cracst! tural Header | Signals Start of Packet 
X-direction reading 
Y-direction reading 


Z Z-direction reading 


(eee Rotation Gives rotation value in 30 degree increments 


Name 









X 
Y 


01 
02 
03 
04 
05 

Flex Gives position of thumb and first three fingers 
07 Switch Gives key codes 
TD endl SAS Se, GSTAT2 |General Status 2 ee 
RECVALS Receiver Values 0 - 
scum mecieaagst 2. ind a er el 
aa pet ok ath 
ee eS a Lae 
Foebies rermoe 
Ly 


A/D port 3. info Give value of third A/D port 0-255 
A/D port 4. info Give value of fourth A/D port 0-255 
A/D port 5 info Give value of fifth A/D _ port 0-255 
A/D port 6 = info Give value of sixth A/D port 


of 
















A/D port 7 info Give value seventh A/D _ port 


Table 3 - Packet Description in Menelli Emulation /Request Mode 
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REND336 


Skeleton 


Program 





Joseph D. Gradecki 


Version 4.01 of 
| REND386 pro- 
| vides the program- 


mer with a variety | 
| of new features. 
| The manner in 


which the develop- 
ment libraries: 
where compiled 
| does not lend itself 
to easy use. This 
Skeleton program 
and set of libraries 
| help to alleviate 
this situation. 





\ Vt the introduction of the 


newest version of REND386, we 
at PCVR would like to cut the 
amount of digging and figuring 
out that you have to do through 
the demo program. To that end, 
we present a skeleton program 
that can be used with REND386 
and its libraries to build your 
own programs. 


The demo program provided 
with REND386 is split into many 
different files and comes close to 
100K of source code. This 1s a 
large amount of information to 
wade through just to create a 
simple program. The program 
skeleton.c on the enclosed disk 
provides a programmer with a 
starting foundation. This pro- 
gram provides the following 
features: 


- Reads initial configuration file 

- Loads video driver 

- Sets up view parameters 

- Reads a command line world file 
- Allows for keyboard processing 


COMPILING 

One problem with the newest 
release of REND386 is that the 
source files provided are specific 
to the demo program. Thus in 
order to program your own 
programs, you must again wade 
through tons of source code to 
find specific parts to the demo 
program. Included on the 
enclosed disk are the libraries 
and object files necessary to 
compile the skeleton program 
and still retain all of the features 
described in the REND386 
documentation. 


The pieces of source code taken 
out of the source files deals 
primarily with the tasks in the 
demo program. These tasks 
controlled such things as the 
spinning sculpture. 


In order to compile the skeleton 
program, a project file should be 
set up that includes the following 
files: 


skeleton.c 
sega.lib 
userint.lib 
rend386.lib 
supp.lib 
render.obj 
gloveptr.obj 
mouseptr.obj 
world.obj 
colormap.obj 
hdmanip.ob] 
cursors.obj 


In most cases, you will want to 
copy the skeleton program to a 
different file so that you always 
have a bare minimum skeleton 
program to begin another pro- 
gramming project. . 


Bear in mind that the libraries 
used to compile the skeleton 
program still retain much of the 
demo program structure. If you 
look at the skeleton code itself 
called skeleton.c on the enclosed 
disk, you will see 20-30 global 
variables that must be included in 
every program that uses the 
REND386 libraries. An 
explaination is given for each of 
their potential use in the demo 
and skeleton programs. |i 
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Graphics 


Joseph D. Gradecki 








In this Graphics 
column, we look at 
the algorithms 
available for simple 
line drawing. 









| Line drawing is 
crucial to any VR 
rendering system. 









The Borland LINE 
function, the 
Brensenham and 
DDA are 
investigated. 









E ach of the previous graphics 
columns had one thing in com- 
mon, they involved line drawing. 
Research into line drawing 
techniques has been extensive 
because every graphics applica- 
tion uses them. In this column, 
we investigate two line drawing 
algorithms, DDA and 
Bresenham. The code for these 
algorithms is compared with the 
Borland C++ 3.1 line drawing 
functions. 


BORLAND 

The simplest way to draw a line 
is to use the graphics library of 
your favorite compiler. Borland 
provides line drawing with the 
folowing function: 


line ( X,Y, x2, y2 } 


A line is drawn using the current 


color setting between the points; 


x, y and x2, y2. Although the 
underlying algorithm for 
Borland’s line drawing function 
is not known, we know that 
however it is done, it must be 
compatible with all video cards 
on the market. Achieving that 
degree of compatibility can be 
difficult. If we are not satisfied 
with Borland’s function, you 
may certainly choose to write 
your own. 


DDA 

The first algorithm we will 
look at is called the digital 
differential analyzer or DDA. 
The basic idea is to take pixel 
steps with one coordinate and 
calculate the new position for 
the other coordinate. In other 





words, if we were to draw a line 
from location (1,1) to (3,3) we 
would start at (1,1) and draw a 
pixel, then step to x = 2 and 
calculate that pixel value for the 
y coordinate. 


All line drawing algorithms are 
based on the following equation 
for a straight line 
y=m*xtb 
M is the slope of the line and b is 
the y intercept. From this we can 
calculate the value for m as: 
y2 - yl 
x2 - xl 
where (x1,y1) and (x2, y2) are 
the points of the line. We can 
also calculate the value of b as: 
b=yl-m* x1 
Let’s look at an example to see 
how the DDA algorithm works. 


Figure | shows a line with a 
positive slope. 


(x2, y2) 


(xy) 


FIGURE 1 


We will draw this line by starting 
with the (x1,y1) coordinate and 
incrementing along the x axis by 
steps of 1. The calculation for 
the y values will be as follows: 


yit1 = yit+m 


So, we take the current value of 
y add the slope value and we 
have the new y value. Consider 
the line for (1,1) to (3,3). We 
know that the first pixel colored 
is 1,1 because it 1s the starting 
pixel. We first calculate the 
slope as m = (3-1) / (3-1) or 1. 
We step to the next x value (2) 
and calculate the y value as yl+1 
=yl+1. Y1=1 so the value 
for y2 is 2 and we color (2,2). 
We do the same for 

(3,3). Once this 1s 

finished our line is 

complete. 


This works well except 


for the fact that the slope yit2 
of a line is not always an 
integer. The slope for  ¥!*1 
the line from (1,1) to yi 
(4,3) is 0.6666667. This 
indicates that the DDA 


algorithm will have to 

adjust itself for real 

numbers. The algorithm does 
this by rounding to the new 
calculated value upon each step. 
The algorithm is shown in Code 
I: 


This algorithm is faster than 
using the standard equation for a 
line but suffers from the use of 
too many floating point opera- 
tions. Each pixel plotted uses 
two floating point additions and 






2) Plot the first pixel 
3) Loop for 1 to largest step 
4) Increment x by delta(x)/steps 
5) Increment y by delta(y)/steps 


6) Plot pixel ( round(x), round(y) ) 


two floating point round opera- 
tions. Far too many for an 
efficient line drawing routine. 
For an example of the DDA 
algorithm in action, check the 
program dda.c on the enclosed 
disk. 


xi xitl xi+2 


Figure 2 


BRESENHAM 

A much faster routine for 
line drawing was developed 
by Bresenham. This algo- 
rithm uses integer arithmetic 
only. Figure 2 shows a 
possible line to be drawn. 


The first pixel in a line has 
been drawn and we need to 
decide which pixel to draw 
on the line next. The choices 
are (xI+1, yl) or 










1) Determine largest step value for line | (xl+1, yl+1). To determine the 


next pixel to draw, we add a 
couple of reference points to 
figure 2 to generate figure 3. 


Figure 3 shows three points. The 
middle point is the original 
position of the line or y. The top 
point is yit+1 and the bottom 
point is yi. D1 is the distance 
between yi and y or 


dli=y-yi 


D2 is the distance between y and 
yit1 or: 


d2 = (yit1) - y 
From the equation of a line, we 
can calculate the position of y to 
be as follows: 

y = m(xit+1) +b 


By simple substitution, 


di = m (xi+1) +b - yi 
d2 = yi+1 - m(xi+1) + b 


The relative distance between d1 
and d2 is: 


dl - d2 = 2m(xi+1) - 2yi + 2b - 1 





xt xitl] xj42 


Figure 3 
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If the distance d1 is less than the 


distance d2, then the pixel will be 
plotted at position (xi+1, yi) 
otherwise it will be plotted at 
position (xi+1, yit1). Using 
various substitutions and calcula- 
tions, the above formula be- 
comes: 


pi = 2delta(y) - delta(x) 
pit+1 = pi + 2delta(y) - 
2delta(x)(yit1 - yi) 


If the value of pi < 0, then use 
the y coordinate pi, otherwise 
use the y coordinate of yi + 1, 
just as in the discussion above. 
The final algorithm appears as 
shown in Figure 4. 


| 1) Get coordinates. 
(x1,y1) is left coordinate, 
(x2,y2) is right coordinate. 
2) Plot (x1, yl ). 


3) Calculate: 


delta(x) = x2 - xl 
delta(y) = y2 - yl 
pi = 2delta(y) - delta(x) 


if pi < 0 then plot (x1+1, yl) 
otherwise plot ( x1+1, y1+1) 


4) Loop for x = x1 to x2 
calculate next pixel using: 


if pi < 0 then 


pit 1 = pi + 2delta(y) 


if pi >= 0 then 


pit 1 = pi + 2(delta(y) - delta(x)) 





For efficiency purposes, the 
delta(x) and delta(y) can be 
precomputed. The program 
bresen.c on the enclosed disk 
shows an example of using the 
Brensenham algorithm. 


SETTING THE PIXEL 

Each of the two algorithms 
above assume a function is 
available to change the setting of 
the pixel on or off. There are 
three ways to plot a single pixel: 
high-level, mid-level, and low- 
level. We will investigate the 
first one and hold the second and 
third for a future graphics col- 
umn because of their complexity. 


High-level 
When we 
think of 
high- 
level, we 
mean at a 
program- 
ming 
level. In 
our case, 
Borland 
C is that 
program- 
ming 
level. 
Borland 
C pro- 
vides the 
function 
putpixel 
for 
plotting 
single 
pixels. 


if ( pi+1 ) < 0 then plot (x, pi ) 
otherwise plot (x, pi+1 ) 


FIGURE 4 
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putpixel (x, y, color ); 


This function plots a pixel of 
color at the coordinate (x, y). 

To determine the execution time 
for putpixel, we plotted 30000 
pixels and divided by the time for 
a execution time of: 


5.33 milliseconds 


TIMINGS 

To determine the fastest of the 
three line drawing functions 
above, a test was setup to draw 
10000 lines at random starting 
and finishing coordinates. The 
results were: 


Line draw lines in 4.62 secs 
DDA draw lines in 60.40 secs 
Bresenham draw in 14.93 secs 


RESULTS : 

From the results shown above, 
it should be obvious that the 
Borland line function uses a form 
of the Bresenham line-drawing 
algorithm but written in assembly 
language. Therefore, the line 
function should be fast enough 
for most purposes, however not 
for VR as we all know. If 


CODE 


The code for this article is called 
graphics.exe on the enclosed disk 
and is a self-extracting execut- 
able file. Refer to the THE 
DISK column for a complete 
description of the extracted files. 


Working 


With 
REND386 
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Joseph D. Gradecki 


In this article, we 
continue to build 
our Virtual Reality 
Racquetball game. 

| We had the ability 
to change our 


viewpoint by . 
panning, tilting, 
and moving our 
| head. 

We also add move- 
ment to the 
racquetball itself. 





‘The previous column in Vol 1 
Issue 5 discussed the creation of 
a racquetball court for our game. 
In this column, we discuss 
adding motion to a ball in the 
court and building a standalone 
structure for the game program. 


STANDALONE STRUCTURE 
Between the time that the 
previous issue went to press and 
the writing began on this issue, 
the development package for 
Rend386 Version 4.01 was 
released. The article “Rend386 
Version 4.01 Skeleton Program” 
in this issue of PCVR documents 
the creation of a skeleton pro- 
gram that can be used to build 
standalone Rend386 programs. 


This program may be compiled 
and executed using the following 
command: 


skeleton court.wid 


Our racquetball court world will 
appear on the screen as in the 
demo program. The only prob- 
lem is that we do not have 
control of the program. We 
cannot move around the court in 
any direction. This is the first 
thing we want to add. Copy the 
skeleton program to another file 
name called rb.c or something in 
order to preserve the original 
skeleton program. 


In the skeleton program, there is 
a function called handle_ key. 
This function is used to program 
certain keys that the user chooses 
to control the program. The 
following options need to be 





added: 
Body and Eye Views 


* Move forward 

* Move backward 

* Move left 

* Move right 

* Turn 90 degrees right 


Eye View 


* Pan the eye view right 

* Pan the eye view left 

* Tilt the eye view up 

* Tilt the eye view down 
A distinction was made between 
the body and the eye view. In 
this game, we visualize our body 
at the plane of the monitor 
screen. Thus our eyes would be 
somewhere in the middle of the 
monitor with our body below it. 
When we move our body, our 
eye view must follow just as it 
does in real life. However, we 
also want to be able to move our 
head left, right and tilt it up and 
down. 


HEAD MOVEMENT 

We will begin with the head 
movements. The head will be 
controlled using the cursors keys. 
The left arrow will cause the 
head to turn to the left, the right 
arrow will cause the head to turn 
to the right, the up arrow will 
cause the head to tilt up, and the 
down arrow will cause the head 
to tilt down. In the handle key 
function, each of the keyboard 
keys are handled using a case 
statement. The case statements 
for each of these keys are: 
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case 0x5000: 
case 0x4800: 
case 0x4D00: 
case 0x4B00: 


left arrow 
right arrow 
up arrow 
down arrow 


For each of these keys, we must 
change the view structure for the 
eye view. This structure has a 
pointer called current_view in 
our skeleton program. Included 
in the structure are the fields: tilt 
and pan. By incrementing or 
decrementing the values in these 
fields, we can change the eye 
view. The units for these fields 
are in degrees. In Rend386, 
degrees are represented in a 
<16.16> format thus any value 
must be multiplied by 65536L in 
order to create the correct 
format. The final code for these 
keys 1s: 


case 0x4800: 
current_view->tilt += 65536L; 
redraw = 1; 

break; 


case 0x5000: 
current_view->tilt -= 65536L; 
redraw = 1; 

break; 


case 0x4B00: 
current_view->pan -= 65536L; 


redraw = 1; 
break; 


case 0x4D00: 
current_view->pan += 65536L; 
redraw = 1; 

break; 


Once compiled, our new pro- 
gram will allow us to look in the 
four new directions. Next we 
will allow our “body” to move. 
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90 degrees. If you stand up and 


BODY MOVEMENT look straight ahead and then turn 
Our body will move using the to the right 90 degrees, you have 
following keys: an idea of what we want to do. 


Y - 90 degree turn right Moving the view 90 degrees is a 


; 2 apis simple matter of panning to the 
- forwar i 

R - Right right. This can be done with the 
L - Left Statement: 


current_view->pan += 90*65536L 


The easiest of these movements 
is the Y; 90 degree turn to the 
right. We wish to accomplish 
two things here: move our body 
90 degrees and move our view 


Don’t forget the 65536L multi- 
plication. Moving our body ts 
another story because up to this 






| case 'b': 

| case ‘B’:current_view->ex -= 50L * sine(current_view->pan); 

current_view->ez -= 50L * cosine(current_view->pan); 

rel_ move_segment (body_seg, -50L*sine(current_view->pan), 
OL, -S0L*cosine(current_view->pan)); 

update_segment ( body_seg ); 

redraw = 1; 










: break; 







| case ‘f’; 

| case ‘F’:current_view->ex += SOL * sine(current_view->pan); 

; current_view->ez += 50L * cosine(current_view->pan); 

rel_move_segment (body_seg, 50L*sine(current_view->pan), 
OL, 50L*cosine(current_view->pan)); 

update_segment ( body_seg ); 

redraw = 1; 










| break; 







| case ‘r’: 

| case ‘R’:current_view->ex += 50L * cosine(current_view->pan); 

| current_view->ez -= 50L * sine(current_view->pan); 

rel_ move_segment (body_seg, 50L*cosine(current_view->pan), 
OL, -SOL*sine(current_view->pan)); 

update_segment ( body_seg ) 

redraw = 1; 











break; 











| case ‘P: 
case ‘L’:current_view->ex -= 50L * cosine(current_view->pan); 
current_view->ez += 50L * sine(current_view->pan); 
rel_move_segment (body_seg, -S0L*cosine(current_view->pan), 
OL, 50L*sine(current_view->pan)); 
update_segment ( body_seg ); 
redraw = 1; 










break; 








point, we do not have a body. 
The main reason for the body 1s 
to control the glove once we add 
it in the next issue. For the time 
being, our body will be a seg- 
ment with no objects attached to 
it. The name of this segment is 
called body_seg and should be 
declared at the top of the pro- 
gram as: 


extern SEGMENT *body_seg 


This segment is defined in an- 
other Rend386 file. It is a rem- 
nant of the demo program that 
we are going to use 1n this 
program. To move our segment 
90 degrees, we use the state- 
ment: 


rel_rot_segment ( body_seg, OL, 
90*65536L, OL, RYXZ ); 


and follow it with: 
update_segment (body_seg); 


in order to update this segment 
and any of its children. The 
remaining movements are not as 
easy as the 90 degree rotation. 
Rend386 is setup to use polar 
coordinates. So if you want to 
move in any direction, you have 
to do more than change the 
appropriate coordinate. We do 
not have the time or space to go 
into polar coordinate systems but 
check any good graphics book 
for a complete explanation. The 
code for each of the movements 
is shown in Code 1. 


In each case, both the eye posi- 
tion and the body segment are 
moved an equal amount of space. 
The 50L 1s a step value so that 


the eye position moves faster. 
You can increase or decrease this 
value as you see necessary. 

After adding all of this and 
compiling the program, you will 
be able to move just about 
anywhere in the scene. The next 
step is to add a bouncing ball. 


BOUNCING BALL 

In order to show how to input a 
plg file into a Rend386 program, 
we have separated our racquet- 
ball from the court world file. 
The ball is called ball.plg. The 


SEGMENT * read_ball0 
{ 
FILE *in; 
OBJECT *ball; 
SEGMENT *ball_seg; 


routine in Code 2 will enter the 
ball into the scene. 


To begin, determine if the file is 
available on the drive. Ifthe 
system is unable to open the 
ball plg file, it will return to the 
command prompt. If the file is 
available, the file should be 
opened. Next, we indicate to the 
system that the ball should be 
scaled by 5x in all coordinates 
and does not have an offset into 
the scene with the statements: 


if ((in = fopen ( “ball.plg”, “r” )) == NULL ) 
{ 


fprintf ( stderr, “Unable to open ball file.\n” ); 


exit(1); 
} 


set_loadpig_ offset (0, 0, 0); 
set_loadplg_ scale (5, 5,5 ); 
ball = load_plg (in ); 

if (load_err !=0) 


fprintf ( stderr, “Error loading ball.plg file.\n” ); 


exit(1); 
} 


add_to_objlist ( objlist, ball ); 
ball_seg = new_seg (NULL ); 
seg _set_object ( ball_ seg, ball ); 


update_segment ( ball_ seg ); 


x_position = 1000; 
y_position = 500; 
zZ_position = 2000; 
inc_val_x = 50; 
inc_val_y = 40; 
inc_val_z = 40; 


return ball seg; 
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set_loadplg_offset ( 0,0,0 ); 
set_loadplg_ scale (5,5,5 ); 


The ball is actually read from the 
file with the command load _plg. 
If the read is successful, the 
variable ball will be a pointer to 
the new object; otherwise it will 
be NULL and the program will 
end. In order for the system to 
render the ball, it must be added 
to an object list. The only object 
list in the program 1s called 
objlist. In addition, we assign the 
ball object to a segment in order 
to allow for easy manipulation. 
This is done with the command: 


seg_set_object ( ball_seg, bail ); 


The segment ball_ seg is in charge 
of the object ball. The last six 
statements of the routine setup 
the movement parameters for the 
ball. X_position, y_ position, 
and z_ position are the current 
positions of the ball in the scene. 
Inc_val_x, inc_val_y, and 
inc_val_z are the values to move 
the ball after each rendering. 


BALL MOVEMENT 

Getting the ball to move is not 
as hard as it may seem. The idea 
is move the bail in a positive 
direction for all coordinates. 
When the ball hits a boundary, 
change the direction of the 
coordinate that hit the boundary. 
The first step 1s to establish the 
boundaries. 


For a racquetball court, the 

obvious boundaries are the court 
walls. To represent these bound- 
aries In Our program, we have six 
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variables defined: 


CEILING 
FLOOR 
LEFT_WALL 
RIGHT_WALL 
BACK_WALL 
FRONT_WALL 


If you look at the court.wld file 
carefully, you will see that the 
coordinate boundary for the 
CEILING and FLOOR 1s the Y 
direction. The floor is at y = 0, 
therefore FLOOR = 0; the ceiling 
is at y = 2400, therefore CEIL- 
ING = 2400. 


For the left and right walls, the 
coordinate boundary 1s the X 
direction. The left wall is at x = 
500, therefore LEFT WALL = 
500; the right wall is at x = 3600. 


For the front and back walls, the 


coordinate boundary is the Z 
direction. The front wall is at Z 
= 4000, therefore 

FRONT WALL = 4000; the 
back wall is at Z = 0, therefore 
BACK WALL = 0. 


These boundaries work but 
occasionally cause the ball to 
slightly disappear when it hits 
any wall. To solve this, we move 
the boundaries 1n by the diameter 
of the ball or SO units. The next 
step is to get the ball moving. 
This is done with a call to the 
function move_ball in the func- 
tion main loop. 


The function move_ball appears 
in Code 3: 


The routines are the same for 
each of the coordinate directions 
so we will look at the Y direction 
only. First, the position of the 
ball is incremented or 
decremented using the inc_ val 
variable. This variable can be 
either positive or negative de- 
pending on the current direction 
of the ball. Once the new posi- 
tion has been calculated, it is 
tested with the appropriate 
boundary. In the case of the Y 
direction, it’s boundaries are the 
CEILING and FLOOR. Ifthe 
new position is greater than the 
ceiling boundary, the direction of 
the ball is changed by making the 
inc_val variable negative. Ifthe 
new position is less than the floor 
boundary, the direction of the 
ball is changed by making the 
inc_val variable positive. 


This increment and check occurs 
for each of the three coordinate 
directions. This works if the 
initial direction of the ball does 
not have equal inc_val variable 
values. In our case, we start the 
ball out with a inc_val_x of 50, 
inc_val_y of 40, and inc val z of 
40. This causes the ball to hit the 
ceiling first and change directions 
immediately. 


PROGRAM 

The final program called RB.C 
on the enclosed disk incorporates 
all of the functions we have 
talked about here. You can 
change the speed of the ball by 
Increasing or decreasing 
BALL SPEED in the source 
code and recompiling. 





NEXT ISSUE 

In the next issue, we will 
discuss the creation of the 
racquet and adding the 
PowerGlove support. Originally, 
we intended to provide Sega 3D 
glasses support but because of 
the lack of documentation in 
REND386 we were unable to 
achieve acceptable results at this 
time. It appears that support for 
REND386 by the authors will be 
limited therefore, we at PCVR 
have begun writing a complete, 
well-documented, and fast 3D 
rendering package. This package 
will include support for all PCVR 
projects as well as future 
projects. Expect the first results 
of the new package in the Vol 2 
Issue 2 of PCVR. If 


CODE : 


The code for this article is called 
rbcourt.exe on the enclosed disk 
and is a self-extracting execut- 
able file. Refer to the THE 
DISK column for a complete 
description of the extracted files. 


void move_ball(SEGMENT *BALL) 
{ 
y_position+=inc_val_y; 
if ( y_position > CEILING ) 
{ 
inc_ val y=-BALL_ SPEED; /* (randQ) % 50);*/ 
y_position+=inc_val_y; 


j 
else if ( y_position <= FLOOR ) 
{ 
inc_val y= BALL SPEED; /* (rand(Q) %50); */ 
y_position+=inc_val_y; 


} 


xX position+=inc_val_x; 
if ( x_position > RIGHT_WALL ) 
{ 
inc_val_ x =-BALL_ SPEED; /*(rand() %50);*/ 
X_position+=inc_val_x; 
} 
else if (x_position < LEFT WALL ) 
{ 
inc val x = BALL SPEED; /*(randQ % 50);*/ 
X_position+=inc_val_x; 


j 


if (inc_val_z>BALL_ SPEED ) inc val z-=1; 
if (inc_val_z<-BALL SPEED ) inc val z+=1; 
Z_positiont+=inc_val_z; 
if ( Z_position > FRONT_WALL ) 
{ 
inc_val_z=-BALL_ SPEED; /*(rand() % 50); */ 
Z_positiont+=inc_val_z; 
j 
else if ( z_position <= BACK WALL ) 
{ 
inc_val_z=BALL_SPEED; /* (randQ) % 50);*/ 
Z_position+=inc_val_z; 


} 


abs_move_segment ( BALL, x_position, y_position, z_position ); 
update_segment ( BALL ); 


} 
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Software 


Library 





QO). of our subscribers 


suggested that we provide a 
library service for those who are 
possibly without Internet or 
Compuserve access. We at 
PCVR are happy to oblige. We 
collected a number of the soft- 
ware packages and 3D games 
available in share and freeware. 
We are offering to buy the disks, 
copy the software, and mail these 
packages to you for $4.50 a 
single disk, and $2.50 for each 
additional disk. The disks are 
5.25 inch 360K for compatibility. 
We have tried to get all the 
software possible on each disk. 
Mail or fax your requests to: 


PCVR 

Attn: Software Library 
1706 Sherman Hill Rd. #A 
Laramie, Wyoming 82070 
(307) 742 - 7675 


Pre-payment is required and 
please include the diske name 
and number when ordering. 


The current disks are: 
Disk# 1 - 
Rend386 Development System - 


Version 4.01 


Includes: Demo4.zip, 
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Devel4.zip, Prims.zip 


This software set contains the 
demonstation program and 
development system for the 
current REND386 system. The 
prims.zip file contains several 
primitive plg objects. 


Disk# 2 - 


Rend386 Conversion and Driver 


Includes: Irit2plg.zip, 
Sdh2plg.zip, Srf2plg.zip, 
Off2plg.zip, 3ds2plg.zip, 
Byu2plg.zip, Combvert.zip, 
Drkit.zip, tesserac. plg 


This software set contains all of 
the REND386 conversion pro- 
grams for objects and the device 
driver source code for Version 
4.01. 


Disk# 3 - Ob ject-Oriented 


~ Glove Interface 


Includes: o2glove.zip 
This is an object-oriented 
Powerglove interface developed 


by Mark Pflaging. 


Disk#4 - 


VR Demos and Serial Interface 


Includes: 3dv25.zip, Pg- 


hcll.zip, Pgtimg.gif; Sscape.zip, 


Vrsdemo.zip 


This diskette contains many VR 


demonstation programs including 


one development using the 
Virtual Reality Studio. The 
Petimg. gif file shows the timing 


for the Powerglove. The file Pg- 


he - }.zip is the complete con- 
struction information for a serial 
Powerglove interface using the 
68hcl1le2 microprocessor from 
Motorola. 


Disk #5 - 
Dr. Dobb’s X-SHARP Package 
Version 21 


Includes: xshp21.zip 


This is the 3D graphics package 
developed in the Graphics col- 
umn in Dr. Dobb's Journal. 


We will add more diskettes as 
demand dictates and when new 
software is made available to the 
shareware and freeware market 
that may be of interest to our 
readers. If 












he enclosed disk includes the following programs: 


sounds.exe - This program is a self-extracting executable file for the 3D SOUND SYSTEM article 
and produces the programs: 


sound. pas sound.exe 


rbcourt.exe - This program is a self-extracting executable file for the WORKING WITH 
REND386 column and produces the programs: 


rb.c courtwal plg ball. plg line.plg 
handle. plg courtwl2.plg thumb. pig palm. plg 
finger2.plg finger1.plg racquet. plg handsm.fig 
racquet.fig court.wld rend386.cfg rbball.c 
rbball.exe rbball. prj vdc256.pvd 


skeleton.exe - This program is a self-extracting executable file for the REND386 Skeleton Program 
article and produces the programs: 


cursors. obj world.obj gloveptr.obj mouseptr.obj 
render. obj hdmanip.obj colormap.obj userint.lib 
supp. lib rend386.lib sega. lib plg.h 
pointer.h rend386.h segasupp.h segio.h 
splitdef.h splits.h tasks.h userint.h 
cursors.c intmath.h f3dkit.h skeleton.c 


skeleton.exe 


graphics.exe - This program is a self-extracting executable file for the GRAPHICS column and 
produces the programs: 


dda.c dda.exe line.c line.exe bresen.c 
bresen.exe 
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Q, September 23rd through the 25th, Meckler Corporation 
hosted Virtual Reality °92 in San Jose, California. This three-day event 
Playground was billed as North America’s Largest Virtual Reality Conference. 


The first day of the conference was filled with tutorials and introduc- 
tions to Virtual Reality. Each of the 30-40 minute presentations focused on a specific part of VR. There 
were speakers from both large and small companies. I found it particularly interesting that some of the 
speakers seemed to be out-of-touch with the real potential of Virtual Reality. Their vision limited itself to 
the research lab. 


A remark, by a dominent figure for a major VR company, shows this strange limit that is placed on this 
technology. They said that they see some interest by the entertainment field and feel that there may be 
some money to be made in this area. I’m sorry but that point is plainly obvious to me and any other 
motivated industry person. There is room for several multi-billion dollar VR companies to ay the 


entertainment industry without saturating the market. 


The second.and third days of the conference continued with sessions on a variety of topics. There was 
talk on affordable VR, military applications, mall-based VR and various other topics. 


During the conference, the attendees could visit an exhibit hall where PCVR magzine as well as other 
vendors were located. Most of the major companies were represented in one form or another. The 
notable exception was VPL. They did not exhibit. 


I made several observations about the VR industry. The most obvious; there were no applications. If 
you want to get rich in this business, create applications. All of the software companies were showing 
walkthroughs of buildings or other worlds but no applications. Virtuality was there but that’s a different 
area of VR. 


The attendance at Virtual Reality 92 was superb. The final numbers are not available but the estimate is 
around 3000. This is significant because the Meckler corporation anticipated 1500. We ran out of 
brochures as did most other companies which meant Kinko’s was a busy place Thursday night. 


Suffice it to say, PCVR will attend VR ’93 in May. We will have several running demonstrations of real 
applications for people to try. We intend on blowing the doors off of high-priced VR with a complete 
system that includes a head-mounted display, input device, head tracker, and software for under one 


~ thousand dollars. 1! 
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